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SUMMARY 


Miranda  was  a low-orbit  technology  satellite  carrying  a number  of  experi- 
mental packages.  A comprehensive  software  system  was  developed  for  its  opera- 
tional support  and  the  processing  of  experimental  data.  This  Report  outlines  the 
various  categories  of  data  processing  employed,  and  describes  each  program  that 
was  provided. 
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INTRODUCTION 


The  UK  technology  satellite,  Miranda^  (1974-13A),  was  launched  on  9 March 

1974.  It  had  an  operational  life  of  nine  months  and  carried  a number  of 

2 

scientific  experiments.  A previous  Report  detailed  the  interfaces  relevant  to 
designing  the  software  packages  described  in  the  present  Report.  The  software 
fulfilled  specific  tasks  which  originated  from  the  requirements  for  operational 
support  , subsystem  evaluation,  and  both  the  immediate  performance  evaluation  for 
and  long-term  analysis  of  the  experiments. 

A decision  was  taken  to  carry  out  all  data-processing  and  operations- 
support  tasks  on  the  Control  Centre  computer.  It  was  in  general  ideal  to  provide 
one  program  per  task  rather  than  to  combine  the  software  for  several  tasks  into 
one  program,  since  most  of  the  objectives  which  had  large  amounts  of  software  in 
common  required  to  process  different  sets  of  data;  also,  computer  space  was 
limited,  magnetic  tapes  (for  program  storage)  were  plentiful,  and  there  was  a 
need  to  maintain  simplicity  wherever  possible.  An  exception  was  with  Quick  Look 
requirements,  where  analysis  for  most  of  the  subsystems  and  experiments  was  per- 
formed in  the  same  program.  The  software  for  experimental  analysis  was  largely 
written  after  launch,  when  the  characteristics  of  certain  parameters  became 
clearly  understood,  in  particular  with  respect  to  attitude  modelling. 

The  programs  which  required  Miranda  telemetry  data  all  obtained  the  data 
from  magnetic  tapes,  written  in  standard  format  (as  specified  in  Ref  2),  and 
referred  to*  as  'digital  tapes'. 

2 CATEGORIES  OF  DATA  PROCESSING 

For  scientific  and  technological  satellites  the  data  processing  commitment 
of  the  operational  Control  Centre  does  not  usually  extend  beyond  data  archiving 
and  simple  quick-look  procedures.  For  Miranda,  however,  the  amount  of  free 
conq>uter  time,  during  hours  of  manning,  was  considered  to  be  adequate  for  all 
the  necessary  data-processing  and  operational-support  activities.  Also  the 
computer  was  considered  sufficiently  powerful  to  perform  all  foreseeable  tasks. 
Thus,  at  an  early  stage,  a decision  was  taken  to  perform  all  Miranda  software 
tasks  on  the  Control  Centre  computer. 

The  time  available  for  data  processing  during  a group  of  morning  or  evening 
passes  was  limited  by  operational  requirements,  whereas  considerable  time  was 

* The  Miranda  Control  Centre  used  two  kinds  of  magnetic  tapes,  containing 
Miranda  telemetry  data  - referred  to  as  'analogue  tapes ' and  'digital  tapes'. 
Analogue  tapes  contained  complete  sets  of  unprocessed  telemetry  data  as  received 
from  the  satellite.  Digital  tapes  contained  complete  passes  of  formatted  tele- 
metry data,  for  direct  use  on  the  conqjuter  magnetic  tape  decks. 
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available  between  groups  of  passes.  For  most  of  the  long-term  experimental 
objectives,  an  assessment  of  in-orbit  data  was  required  before  methods  of  analysis 
could  be  finalised.  There  was  also  a four-  to  six-week  delay  in  obtaining  the 
good  orbital  elements  which  most  of  the  experimental  data  processing  needed. 
Furthermore  the  effort  available  for  system  design  and  software  production  was 
limited  - it  being  mainly  available  during  the  year  before  and  the  year  after 
launch.  Thus  the  various  data  processing  activities  had  to  be  categorised,  to 
allow  essential  aspects  to  be  undertaken  with  minimum  delay,  while  retaining 
sufficient  flexibility  to  cope  with  anomalous  situations  and  not  incurring 
unnecessary  delays  in  other  data  processing.  When  formalising  the  data- 
processing  and  operations-support  requirements  for  the  satellite  controller, 
technical  advisers  and  experimenters,  the  following  categories  were  used. 

2. 1 Pre-pass 

This  category  of  processing  was  mainly  related  to  the  scheduling  of  passes 
and  events  which  would  influence  the  course  of  a pass. 

2.2  Immediate  post-pass 

Assuming  computer  availability,  as  much  routine  data  processing  as  possible 
is  ideally  done  immediately  after  each  pass.  The  program  QLK  was  written  for 
this  purpose  - it  covered  evaluation  of  the  performance  of  most  of  the  Miranda 
subsystems,  as  well  as  the  initial  processing  for  the  satellite  experiments,  and 
included  the  routines  which  evaluated  and  summarised  the  operational  status  of 
the  satellite  for  the  Satellite  Controller. 

Also  included  in  this  category  of  processing  were  the  programs  used  in  the 
evaluation  of  attitude  manoeuvres  for  earth  and  star  acquisition.  These  programs 
required  the  latest  information  relating  to  the  attitude  of  the  satellite,  in 
order  to  determine  the  necessary  command  sequences  to  be  sent  to  the  satellite 
on  subsequent  passes. 

2.3  Other  post-pass  regular 

From  the  outset  it  seemed  likely  that  on  occasions  time  would  not  permit 
all  routine  processing  to  be  performed  immediately  after  a pass;  hence  there  was 
a category  of  processing  which  incorporated  those  requirements  for  which  a delay 
of  two  to  three  hours  would  cause  no  inconvenience. 

2.4  Long-term 

Any  data  processing  requirement  which  required  good  attitude  and  orbital 
data,  and  which  did  not  affect  the  general  operations  plan,  was  considered  to 
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fall  into  this  category.  This  covered  the  major  part  of  the  data  processing  for 
the  experiments  which  were  also  dependent  on  an  assessment  of  in-orbit  data  to 
finalise  definition  of  methods  of  analysis. 

During  the  periods  of  experimental  interest,  attitude  manoeuvres  were  often 
performed:  these  were,  however,  confined  to  periods  of  direct  data,  so  that 
during  each  period  of  recorded  data  the  pitch  rate  was  constant.  Further  it  was 
possible  to  derive  the  satellite  attitude  accurately  as  a simple  function  of 
time  from  the  data  received  during  a pass.  For  the  particular  programs  it  was 
thus  considered  essential  to  provide  automatic  methods  of  attitude  determination 
using  only  data  from  the  pass  under  analysis. 

The  programs  for  the  analysis  of  the  experimental  data  are  described  in 
separate  sections  for  Experiments  A,  B,  C and  D. 

2 . 5 Available  on  request 

Data  processing  experience  oH  other  gatellites  had  shown  that  it  was  im- 
possible, within  reasonable  bounds,  for  routinely  used  software  to  cover  all 
contingencies.  Furthermore,  were  it  possible,  the  amount  of  computer  output 
1 would  be  too  great  for  assimilation.  It  was  therefore  considered  necessary  to 

[ make  available  a group  of  programs  which  could  list  any  selected  set  of  tele- 

t 

t metry  parameters. 

There  were  also  utility  programs,  which  were  built  from  modules  of  other 
software  to  meet  minor  but  recurrent  needs. 

3 PRE-PASS  PROGRAMS 

3. 1 Program  for  Look  Angle  Prediction  (PLP) 

Given  the  orbital  elements  of  the  satellite,  the  location  of  a ground 
station  and  an  (extended)  period  of  time,  PLP  searched  for  the  periods  of  time 
during  which  the  satellite  was  above  the  horizon.  (For  a more  detailed  descrip- 
tion '6130PLAF'  of  Ref  4 should  be  consulted.) 

Input  was  controlled  by  commands  typed  on  the  console.  Though  all  the 
data  could  be  input  via  the  console,  it  was  naturally  more  convenient  to  input 
the  orbital  elements  via  the  tape  reader  since  they  arrived  on  5-track  paper 
tape.  If  periods  of  visibility  were  required  for  more  than  one  station,  the 
input  of  station  co-ordinates  was  again  via  the  tape  reader. 

Some  output  was  generated  on  the  console  and  some  on  the  lineprinter. 

I Console  output  occurred  when  the  computer  was  waiting  for  a command  or  for  data. 

Output  on  the  lineprinter  consisted  of  orbital  elements  as  read  from  the  tape 


reader,  followed  by  the  heading  'look  angles  from  La sham ' , day  number,  date,  and 
a tabulation  of  time,  elevation,  and  azimuth  during  the  period  the  satellite  was 
above  the  nominal  horizon.  The  usual  period  of  predictions  was  14  days,  so  the 
program  was  run  once  a fortnight. 

3.2  Program  to  produce  Orbit  Summary  (PALI) 

PALI  extended  the  orbital  elements  of  the  satellite  read  in  from  5-track 
paper  tape  to  a set  of  constants  required  by  PAL2  and  transferred  them  to  a 
special  storage  area  on  a serial  disc.  When  supplied  with  a day  number  via  the 
console,  an  'orbit  summary'  of  various  parameters  including  perigee  height, 
apogee  height  and  inclination,  appeared  on  the  lineprinter  - an  example  is  given 
in  Fig  1 . 

The  program  was  run  whenever  an  orbit  summary  was  required  for  a particular 
day,  and  whenever  more  recent  elements  became  available,  provided  that  this  would 
not  interfere  with  the  continuity  of  gyro  assessment  analysis  (as  logged  by 
PAL2  - see  section  5.1). 

3.3  Eclipse  Angle  Prediction 

This  program  was  used  to  monitor  the  onset  of  eclipse.  It  provided 
horizon  depression-angle  data  over  part  of  each  orbit.  This  was  used  to  predict 
two  phenomena:  (i)  the  times  when  the  albedo  or  spectrally  reflected  light 
would  enter  the  field  of  view  of  the  fine  sun  sensor  - as  it  was  thought  that 
this  might  cause  an  offset  of  the  pitch  axis;  and  (ii)  the  start  of  eclipse. 

The  program  generated  satellite  position  in  one-minute  steps,  printing 
out  the  depression  angle  of  the  earth's  horizon  from  the  sun-direction  whenever 
this  was  less  than  30°. 

The  program  used  SDC  orbital  elements  as  input  data  and  was  run  whenever 
new  orbital  elements  were  available.  The  lineprinter  output  consisted  of  the 
depression  angles  tabulated  against  time. 

4 IMMEDIATE  POST-PASS  PROGRAMS 

4. 1 Quick  Look  (QLK) 

QLK  was  used  to  provide  the  operations  group,  technical  advisers  and  experi- 
menters with  partly  analysed  satellite  data,  as  soon  as  possible  after  a pass. 

The  date-control  software  (see  Appendix)  was  designed  for  processing 
digital  tapes,  and  it  enabled  a number  of  mutually  exclusive  user  requirements 
to  be  effectively  met  in  parallel.  Thus  the  QLK  processing  for  one  person  in  no 
way  affected,  or  was  affected  by,  the  requirements  of  others. 
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The  program  was  limited  by  the  size  of  the  computer,  but  this  caused  no 
problems  as  there  was  another  program  - RLK  (see  section  5.2)  - for  meeting 
routine  requirements  for  which  delays  of  a few  hours  would  be  tolerable.  The 
QLK  data  processing  covered  the  following 

(i)  the  operations  group; 

(ii)  the  power  subsystem; 

(iii)  the  data  handling  subsystem; 

(iv)  all  satellite  temperature  monitors; 

(v)  optimum  gain  evaluations  for  the  IR  sensor; 

(vi)  the  initial  and  final  frame  counts  for  each  batch  of  data; 

(vii)  Experiment  B; 

(viii)  Experiment  C; 

(ix)  Experiment  E. 

The  program  obtained  satellite  data  from  a digital  tape  and  produced  one 
lineprinter  sheet  for  each  of  the  above  requirements,  suitably  annotated  and 
automatically  addressed  for  distribution.  An  example  of  the  output  for  require- 
ment (iv)  is  given  in  Fig  2. 

4.2  Star  Lock/Look  (SLK) 

(a)  Operations  plan 

To  give  an  adequate  description  of  SLK,  it  is  first  necessary  to  refer  to  the 
operational  sequence  of  events  that  were  adopted  to  achieve  star  lock.  This 
sequence,  for  a series  of  consecutive  passes  was  as  given  in  the  table  below. 

Pass  Event 

E^  Command:  Mode  3 (inertial  sun-lock) 

Command:  0 /h  pitch  rate 


Collect  telemetry  data 
Run  SLK  prior  to  next  pass 


«2 

At 

T,: 

Command : 

alignment  pitch  rate 

(M3) 

No 

action 

= 1 

At 

T2: 

Command : 
Conmand : 
Conmand : 

Mode  5 (star  acquisition  and  lock) 
±20°/h  (as  selected) 

Pitch  integrator  to  0°/h 

E2  Assess  lock 

(E^)  Assess  lock 


Note:  M and  E denote  Morning  and  Evening  passes;  in  principle  the  sequence  could 
equally  well  have  been  started  with  an  M^  pass,  but  it  was  generally  more  practi- 
cal to  make  the  star-lock  assessment  phase  in  the  evening. 


A 


A 


A 


A 


f 


T 
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The  times  Tj  and  T2  were  selected  by  the  Satellite  Controller,  before 
starting  the  star-lock  procedure,  as  times  which  were  convenient  for  command 
sending. 

Setting  the  satellite  to  0°/h  pitch  rate,  at  the  start  of  the  sequence, 
was  considered  to  be  necessary  when  the  operational  sequence  and  the  program  SLK 
were  originally  formulated.  At  that  time,  due  to  inadequate  telemetry  accuracy 
of  the  parameters  from  which  the  pitch  rate  was  deduced,  it  was  considered  that 
a known  particular  pitch  rate  should  be  set  and  that  this  should  be  zero.  Sub- 
sequent analysis  of  in-orbit  data,  however,  showed  how  the  telemetry  could  be 
used  to  determine  the  pitch  rate  uniquely,  so  that  in  principle  the  0°/h  command 
could  have  been  omitted  and  the  operational  sequence  started  at  Mj . These  modi- 
fications were  in  fact  incorporated  during  the  late  summer  when  it  was  found 
that  it  was  necessary,  because  of  the  coldness  of  the  South  pole,  to  change  the 
method  of  horizon  detection  (previously  used  by  SLK)  from  fixed-threshold- IR 
sensing  to  rate-of-change-of-IR-signal  sensing. 

The  ±20°/h  drive  rates  (prime  rate  combinations  of  +12°/h  and  +8°/h  or 
-12°/h  and  -8°/h)  were  selected  to  maximise  the  chance  of  observing  the  star 
with  sufficient  time  for  the  ACS  to  update  the  pitch-integrator  compensation 
loop,  before  the  star  signals  were  cut  off  by  the  earth-albedo-protection 
sensors. 

For  controlling  the  pitch  rate  the  satellite  contained  a 12-bit  register 
(known  as  the  pitch  integrator  register)  which  biased  the  pitch  gyro  at  any 
selected  rate  with  magnitude  up  to  30°/h.  This  had  to  be  used  whenever  an 
accurate  pitch  attitude  was  subsequently  required  at  a given  instant;  also 
it  was  much  more  convenient  if  it  could  be  used  with  0°/h  prime  rate  (rather 
than  with  any  of  the  other  rates)  during  an  alignment  manoeuvre.  Since  the 
operational  requirement  was  to  achieve  star  lock  on  the  selected  star,  starting 
from  any  satellite  pitch  attitude,  the  times  T|  and  T^  had  to  be  chosen  at  least 
six  hours  apart  (and  in  practice  about  ten  hours  apart)  so  that  an  alignment 
manoeuvre  was  always  possible  by  suitable  choice  of  pitch  alignment  rate  to  be 
commanded  at  Tj.  The  satellite  would  then  be  in  the  correct  orientation  at  T^ 
for  the  selected  20°/h  sweep  rate  to  be  commanded  with  the  Mode  5 star-lock- 
initiate  command. 

The  program  could  be  used  for  a atar-look  exercise  instead  of  a Btar-loak 
exercise,  by  simply  omitting  the  Mode  5 command  at  T2. 
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(b)  Program  description 

The  primary  objective  of  SLK  was  to  evaluate  the  alignment  rate  command  tr 
be  sent  to  the  satellite  at  time  Tj.  Essentially  two  major  items  had  to  be 
evaluated  - the  attitude  (ie  pitch  angle)  that  the  satellite  was  expected  to 
have  at  time  Tj,  and  the  attitude  that  it  was  required  to  have  at  time  T2. 

From  the  telemetry  data  (usually  recwlved  during  the  Mj  pass),  horizon 
crossings  (as  indicated  by  the  changing  signals  of  the  IRj  detector)  were 
analysed  to  provide  horizon-position-reference  times.  Then,  using  the  satellite 
and  sun  positions  at  those  times,  the  attitudes  were  evaluated.  A straight  line 
was  fitted  through  the  attitude-time  points  at  the  known  pitch  rate  (usually 
0°/h) , from  which  the  attitude  at  Tj  was  extrapolated. 

In  order  to  evaluate  the  required  satellite  attitude  at  T^,  the  character- 
istics of  the  star-sensor  and  attitude-control  protection  systems  were  employed. 
There  was  a glare  detector,  which  operated  automatically,  and  an  infra-red 
detector  (IR4)  which  could  be  brought  into  use  by  ground  command.  Since  the 
characteristics  of  the  glare  detector  were  not  fully  determinable  before  launch 
it  was  initially  decided  to  employ  IR4.  Its  field  of  view  was  in  the  opposite 
direction  to  that  of  the  star  sensor  and  its  principle  of  use  was  that  only  when 
it  was  sensing  infra-red  radiation  from  the  earth  did  it  allow  the  star-sensor 
signals  into  the  attitude  control  system.  This  was  over  the  part  of  the  satel- 
lite's orbit  which  lay  between  the  earth  and  the  star.  SLK  evaluated  the  times, 

T and  T , at  which  the  satellite  would,  respectively,  enter  and  leave  this 
A S 

part  of  the  orbit,  subsequent  to  the  time  T^.  Then,  if  T^  was  the  time  at 

^ich  it  was  aimed  to  first  observe  the  star,  the  period  between  T and  T 

b B 

could  be  used  by  the  ACS  to  update  the  pitch-integrator  compensation  of  the  pitch 

gyro  drift.  Thus  ideally  T^  should  have  been  as  close  as  possible  to  T^  . 

The  predicted  attitude  at  T^  was,  however,  subject  to  extrapolation  errors 

over  a period  of  ten  to  twelve  hours,  for  which  adequate  allowance  had  to  be 

made  - so  the  most  suitable  estimate  of  T was  taken  to  be  given  by: 

o 

T„  - 0.75T.  + 0.25T_  . 

0 Ad 

When  in  orbit,  however,  the  glare  detector  (which  operated  automatically) 

was  surprisingly  restrictive.  It  allowed  the  sensor  to  operate  between  a pair 

of  times,  T.  + t.  and  T_  + t„,  say,  where  t,  and  were  both  positive 

A A 00  A D 

and  virtually  constant.  Thus  in  practice  it  was  found  that  Tg  was  better 
given  by  Tg  - 0.43T^  + 0.57Tg  . Also  in  practice,  it  was  found  that  the 
period  between  T^  ♦ and  Tg,  allowed  by  the  use  of  both  protectors  was 
inadequate,  so  IR^  was  not  used  for  control-system  protection. 
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From  a knowledge  of  Che  star  and  sun  directions,  and  the  orientation  of 
the  star  sensor  in  the  satellite,  the  required  attitude  for  observation  of  the 
star  at  Tg  was  determined,  and  using  the  selected  drive  rate  the  required 
attitude  at  T2  was  computed. 

Knowing  the  times  Tj  and  T^,  and  having  determined  the  satellite  atti- 
tude at  Chose  times,  SLK  determined  the  required  alignment  rate,  which  was  con- 
verted to  the  actual  command  pattern  that  had  to  be  sent  to  Miranda. 

Finally,  from  a knowledge  of  Che  star  and  sun  directions  the  angle  between 
them,  ie  Che  elongation,  was  computed  and  hence  the  optimum  setting  of  the  star- 
sensor mirror  was  evaluated. 

The  program  used  a selected  pass  of  data  from  a digital  tape  (usually  the 
actual  tape  which  was  made  in  real-time;  see  APP  - section  5.3)  and  required 
orbital  elements.  It  also  required  information  to  be  provided  on  a special  form, 
an  example  of  which  is  given  in  Fig  3. 

The  lineprinter  output  gave  the  alignment-rate  command  and  Che  required 
star-sensor  mirror-position  number,  together  with  annotated  details  of  the  major 
stages  of  confutation,  so  ensuring  that  anomalous  situations  would  be  observed  - 
such  as  when  the  radiance  from  the  South  pole  was  below  the  horizon-detection 
threshold.  Fig  4 gives  the  output  corresponding  to  the  data  of  Fig  3. 

4.3  Special  Earth  Lock 

The  program  evaluated  the  pitch-attitude  manoeuvres  which  would  set  the 
satellite  at  the  required  attitude  for  an  earth-pointing  exercise.  This 
initially  required  85  to  90  elements  of  the  100-elemenC  albedo  array  pointing 
below  the  horizon  and  the  remainder  looking  out  to  space,  so  that  the  pitch-rate 
could  be  commanded  to  orbital  rate  at  that  time. 

The  procedures  adopted  were  almost  identical  to  the  SLK  procedures  up  to 
the  selected  time  T^*  At  that  time  the  attitude  had  to  be  correct  for  the 
commanding  of  a pitch-rate  equal  Co  orbital  rate. 

The  input  data  consisted  of  a digital  tape  and  SDC  orbital  elements.  In 
addition  the  times  Tj  and  T2  were  input  via  the  console.  The  output  con- 
sisted of  a lineprinter  sheet  giving  details  of  the  attitude  modelling,  the 
attitude-time  points,  the  alignment  rate  command  and  the  pitch  integrator  value 
required  to  trim  Che  nominal  orbital  rate  into  the  actual  orbital  rate. 
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5 POST-PASS  REGULAR  PROGRAMS 

5. 1 Pitch  Attitude  Log  (PAL2) 

The  main  object  of  PAL2  was  to  produce  a continuous  log,  on  lineprinter 
paper,  of  all  events  significant  to  the  ACS  experiment  (Experiment  A)  - Fig  5 
gives  a typical  page  of  output.  A subsidiary  object  was  the  updating  of  a Pitch 
Measurement  File,  held  on  magnetic  tape.  The  relation  between  the  Pitch  Attitude 
Log  and  the  Pitch  Measurement  File  was  that  a measurement  number  was  allocated 
to  certain  of  the  PAL  'significant  events'  and  that  information  relating  to  the 
numbered  events  was  stored  in  a record  of  the  Pitch  Measurement  File,  one  record 
to  each  event.  The  events  of  principal  interest  were  measurements  of  pitch 
attitude  by  sensors  associated  with  Experiments  A,  B,  C and  D.  For  detail  about 
the  Pitch  Attitude  Log,  beyond  that  given  in  this  section.  Ref  5 should  be 
consulted. 

The  program  was  run  after  every  pass  and  included  data  in  chronological 
order.  To  achieve  continuity,  lineprinter  output,  corresponding  to  an  incomplete 
lineprinter  sheet,  was  held  on  a disc  file  in  such  a way  that  the  output  from  the 
next  PAL2  run  would  reproduce  this  sheet  with  extra  material  added. 

The  Pitch  Measurement  File  was  updated  through  a 'father-son'  editing 
procedure  with  a 'grandfather'  tape  held  in  reserve  as  a precaution  against  tape 
damage.  This  file  was  required  by  other  programs  (see  sections  7.1  and  7.2)  in 
the  assessment  of  the  performance  of  the  gyroscopes. 

The  log  consisted  of  eight  columns  as  follows :- 

(i)  Date. 

(ii)  Universal  time. 

(iii)  Argument  of  latitude. 

(iv)  Measurement  number:  this  was  the  serial  number  referred  to  for 
attitude  measurements;  it  was  generated  whenever  such  a measurement  was 
made  unless  the  satellite  was  controlled  bj  active  pitch  sensing.  In 
addition,  pseudo  numbers  were  generated  corresponding  to  any  change  in 
satellite  status  and  to  all  crossings  of  the  Lasham  latitude,  whether  data 
was  being  collected  at  such  times  or  not. 

(v)  Pitch  angle  relative  to  ecliptic  north. 

(vi)  Pitch  angle  relative  to  the  plane  defined  by  the  earth-sun  line  and 
the  local  vertical  at  the  instant  the  satellite  crossed  the  Lasham  latitude. 
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(vii)  A multiple  column  indicating  ACS  status;  individual  characters  of 
this  indicated  the  satellite  mode,  its  pitch  rate,  the  pitch  integrator 
constant  whenever  applicable,  gyro  status  and  gas  jet  status. 

(viii)  A column  containing  codes  which  identified  any  ground  commands  sent 
and  the  type  of  sensor  involved  in  an  attitude  measurement,  etc.  Entries 
in  the  log  were  in  chronological  order.  Special  entries  indicated  the 
beginning  of  data  from  a new  pass  (code  NP)  and  the  end  of  data  (EP) . The 
amount  of  gas  present  was  evaluated  at  the  start  and  end  of  a pass,  thus 
enabling  an  estimate  to  be  made  of  the  gas  consumed. 

5.2  Routine  Look  (RLK) 

This  program  was  essentially  an  extension  of  QLK,  covering  requirements  for 
which  delays  of  a few  hours  would  be  tolerable.  In  fact  most  of  the  requirements 
which  fell  into  this  category  were  fitted  into  QLK,  leaving  only  two  requirements, 
each  of  which  was  relatively  large.  The  first  was  to  give  complete  images  of 
the  100-element  albedo  sensor,  for  both  recorded  and  direct  data.  The  second 
was  to  provide  an  elementary  star  map  - consisting  of  the  active  star-sensor 
outputs  together  with  the  great-circle  sky  track  on  which  the  sensor  could 
observe.  (The  long-term  data  processing  used  other  star  mapping  programs  - 
see  section  9.) 

RLK  obtained  satellite  data  from  digital  tapes.  In  addition,  SDC  orbital 
elements  were  required.  The  output  was  to  the  lineprinter,  suitably  annotated 
and  addressed. 

5.3  Append  (APP) 

The  basic  system  for  generating  Miranda  digital  tapes  involved  the  transfer 

of  data  from  a single  pass  - normally  digitised  real-time  - to  a scratch  tape, 

2 

storage  being  in  a standard  format  , in  which  the  end  of  data  was  recognised 
by  a pair  of  consecutive  tape-marks.  To  retain  a separate  tape  for  every  pass 
would  have  been  inconvenient  and  uneconomical,  so  APP  was  written  to  concatenate 
multi-pass  data  to  a single  tape,  the  individual  passes  each  being  terminated  by 
single  tape-marks.  The  term  'digital  tape'  then  became  applicable  equally  to 
the  basic  tapes  and  to  concatenated  tapes,  the  former  being  effectively  special 
cases  of  the  latter. 

The  operational  requirement  was  to  keep  one  tape  for  each  day's  data.  Thus 
APP  was  normally  run  once  per  day.  Any  output  tape  was  automatically  valid  as  an 
input  tape,  however,  so  the  concatenation  could  be  performed  in  several  stages. 
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Operation  of  the  program  was  straightforward.  APP  was  told,  via  the 
console,  the  number  of  input  tapes  and  the  serial  number  of  the  output  tape.  All 
information  from  each  input  tape,  in  the  order  loaded,  was  copied  to  the  output 
tape,  including  header  blocks  and  tape-marks,  until  a pair  of  consecutive  tape- 
marks  was  located,  of  which  only  the  first  was  copied.  With  the  last  tape,  of 
course,  the  second  tape-mark  was  copied  as  well,  to  indicate  tape  terminations. 

5.4  Digital  Tape  Log  (LOG) 

LOG  gave  a brief  summary  of  the  information  contained  on  a digital  tape. 

It  counted  the  number  of  direct  and  replay  frames  in  each  pass,  noting  the  time 

of  the  initial  and  final  frames.  It  also  counted  the  number  of  frames  that 

2 

failed  the  checksum  test  , and  computed  the  bit  error  rate. 

Lineprinter  output  (identifiable  by  the  tape  serial  number,  copied  from 
console  input)  consisted  of  the  following  items  for  each  pass:  (a)  the  tape 
number;  (b)  header  block;  (c)  initial  and  final  frame  times  and  count  numbers; 

(d)  the  number  of  direct  and  recorded  frames  that  were  good  and  bad;  (e)  the 
error  bit  rate. 

The  program  was  run  every  day,  usually  after  APP  (section  5.3),  to  provide 
a summary  of  the  daily  digital  tape. 

6 UTILITY  PROGRAMS 

6. 1 Emergency  Look  (ELK) 

Two  versions  of  this  program  were  available.  The  first,  or  standard  ELK, 
could  provide  up  to  14  columns  of  time-ordered  sets  of  data  on  the  lineprinter, 
using  a selected  pass  of  data.  The  alternative  version,  referred  to  as  Extra 
Word  Look  (XLK) , could  provide  up  to  10  columns  of  time-ordered  sets  of  data, 
together  with  the  associated  extra  words  (see  Appendix  of  Ref  2).  The  standard 
ELK  was  used  very  extensively,  some  2000  times  during  the  life  of  the  satellite, 
while  XLK  was  rarely  used. 


The  programs  were  designed  around  a special  data  form,  see  Fig  6,  on  which 
the  analyst  could  fill  in  the  syllable  number  and  minor  frame  identity  for  each 
of  the  desired  parameters.  The  minor  frame  identities  were  0,  1,  ....,  7 

for  distinct  minor  frames,  or  'A*  for  all  minor  frames,  while  syllable 
numbers  were  the  standard  octal  values  given  in  the  Appendix  of  Ref  3.  Each  set 
of  data  could  be  output  in  octal  (thus  providing  easy  status  recognition)  or  in 
decimal.  A letter  'O'  in  the  last  column  called  for  output  of  that  set  of  data 
to  be  in  octal  - octal  values  being  identifiable  by  a preceding  asterisk.  If 
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known,  the  initial  frame-counter  value  and  the  number  of  frames,  for  the  data  of 
interest,  could  be  entered  on  the  form,  otherwise  the  coiiq>lete  pass  of  data  was 
used.  The  special-data-form  information  was  input  line  by  line  on  the  console. 

Each  line  that  did  not  conform  to  the  specified  syntax  was  immediately  rejected, 
thus  minimising  the  effects  of  operator  error. 

The  program  scanned  the  selected  pass  of  data  from  a digital  tape  and 
provided  one  line  of  output  on  the  lineprinter  for  each  minor  frame  within  the 
specified  range  of  frame  counts  for  which  data  was  required.  Fig  7 gives  the 
output  corresponding  to  the  input  of  Fig  6. 

6.2  ACS  Parameter  Lists  (WLK) 

The  program  WLK  was  in  many  ways  similar  to  ELK.  It  required  a special 
data  form,  shown  in  Fig  8,  and  provided  columns  of  time-ordered  sets  of  data  on 
the  lineprinter  from  a selected  pass  of  data  on  a standard  digital  tape. 

Either  or  both  of  two  data  scans  could  be  requested;  the  first  produced 
up  to  13  sets  of  data,  modified  according  to  specified  calibrations,  the  second 
produced  values  of  the  roll,  pitch  and  yaw  integrators,  together  with  up  to  10 
sets  of  data  in  octal.  Since  the  ACS  parameters  were  not  sub-commutated,  only 
syllable  numbers  were  required  to  identify  parameters.  The  initial  and  final 
counter  values  (of  the  band  of  interest)  had  to  be  entered  on  the  form,  and  data 
was  input  in  the  same  way  as  in  ELK.  The  lineprinter  output  consisted  of  a line 
of  data  for  each  minor  frame  in  the  band  of  interest,  for  each  of  the  selected 
scans. 

6.3  Elongation  Angle 

The  angle  subtended  at  a satellite  by  any  particular  star  and  the  sun  is 
known  as  the  elongation  of  the  star.  During  the  course  of  a year  this  angle 
varies,  approximately  sinusoidally.  The  Miranda  attitude  control  system  kept 
the  satellite's  pitch  axis  in  the  sun-pointing  direction,  and  the  star  sensor 
contained  a mirror  which  could  be  rotated  to  change  the  sensor's  field  of  view. 

For  purposes  of  experimental  planning,  it  was  necessary  to  know  the  times  during 
the  year  when  the  sensor's  field  of  view  could  accommodate  a selected  star. 

The  distance  of  the  satellite  from  the  centre  of  the  earth  being  negligible 
in  comparison  with  distance  of  the  stars  and  sun  from  the  centre  of  the  earth, 
the  program  only  needed  to  use  sun  and  star  data.  The  input  to  the  program 
consisted  of  right  ascension  and  declination  of  the  selected  star  and  the  line- 
printer  output  gave  the  elongation  angle  and  best  mirror  position  number 
1200  GME  for  each  day  of  the  year. 


07 


17 


6.4  Attitude  for  Star  Observation 

Owing  to  the  nature  of  the  operations  involving  the  star  sensor,  it  was 
desirable  to  have  available  a simple  and  quick  method  of  checking  possible  star 
observations.  Satellite  attitude  information  was  readily  available,  so  this 
program  was  formulated  to  compute  the  satellite  attitude  that  would  be  necessary 
for  observation  of  any  particular  star.  Since  the  satellite's  pitch  axis  always 
pointed  at  the  sun,  and  its  orbital  position  was  close  to  the  centre  of  the 
earth,  relative  to  the  positions  of  the  sun  and  stars,  the  required  attitude  was 
only  a function  of  the  selected  star  and  time  of  year.  The  input  data  consisted 
of  the  right  ascension  and  declination  of  the  selected  star  together  with  the 
day  nundjer.  The  linepr inter  output  gave  the  input  data  together  with  the 
necessary  attitude  as  evaluated  at  the  day.  (The  attitude  angle  was  the  angle 
between  the  yaw  axis  and  the  plane  containing  the  sun  direction  and  north-polar 
direction,  see  Fig  9.) 

6.5  Oddities  on  a Digital  tape  (ODD) 

ODD,  analysed  a selected  pass  of  data  from  a digital  tape  and  listed  events 
that  might  be  regarded  as  'oddities’.  It  looked  at  four  items  for  each  frame  of 
data:  the  checkword;  the  time  indicated;  the  frame  counter;  and  whether  direct 
or  replay.  The  initial  frame  time  t^  (say)  and  frame  counter  Cj  were  stored, 
and  a note  made  of  whether  the  data  was  in  direct  or  replay  mode.  The  program 
predicted  that  the  next  frame  time  would  be  t,  + 0.5  s (±0.1  s),  that  c, 
would  be  superseded  by  Cj  1 (mod  2 ),  and  that  direct  data  would  remain 

direct  (and  replay  remain  replay) . If  the  prediction  was  not  satisfied  the 
'oddity'  (or  oddities)  would  be  listed  and  a prediction  made  for  the  next  frame 
assuming  the  time  etc  to  be  as  at  the  oddity  frame.  This  process  was  repeated 
until  the  end-of-pass  tape-mark  was  reached. 

The  detected  oddities  were  listed  on  the  lineprinter  through  messages  such 

as:  'time  not  correct,  predicted  time  obtained  time  ';  'direct 

predicted,  replay  obtained',  'checkword  not  equal  to  1',  or  'count  did  not  check, 
predicted  count  obtained  count  ' . 

The  program  was  run  whenever  there  was  a suspicion  of  faulty  data. 

7 PROGRAMS  FOR  EXPERIMENT 

7. 1 Smoothing  of  Pitch  Attitude  Measurements  (SPAM) 
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SPAM  made  a least-squares  time-linear  fit  to  the  attitude  measurements 
obtained  from  the  IRl  detector.  Observations  with  residuals  exceeding  three 
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standard  deviations  were  excluded  and  the  least-squares  fit  procedure  repeated 
with  the  remaining  observations.  Examination  of  SPAM  output  has  shown  that 
rejections  were  all  due  to  errors  in  the  timing  of  recorded  data,  resulting  from 
the  fact  that  this  timing  was  not  fully  automatic  - see  the  comments  in  Ref  2. 
Finally,  all  attitude  measurements  (from  the  infra-red  sensor,  albedo  sensors 
and  star  sensor)  were  examined  and  any  which  differed  by  more  than  2°  from  the 
fit  function  eliminated  (see  Ref  5) . 

Input,  via  the  console,  consisted  of  the  initial  and  final  measurement 
numbers  of  the  interval  to  be  covered,  together  with  the  measurement  numbers  of 
any  measurements  to  be  rejected  ab  initio.  Measurement  numbers  and  pitch  angles 
were  read  from  the  Pitch  Measurement  File  produced  by  PAL2  (see  section  5.1). 

The  following  items  were  output  to  the  lineprinter :- 

(i)  Reference  date  assuming  an  understood  reference  time  at  zero  hours 
on  that  date. 

(ii)  The  first  measurement  number  specified  in  the  program  input  (which 
might  have  been  rejected  in  the  processing),  together  with  its  time  rela- 
tive to  the  reference  time. 

(iii)  The  first  three  sub-columns  of  the  status  column  in  the  Pitch 
Attitude  Log,  giving  the  ACS  mode  and  the  nominal  pitch  rate. 

(iv)  The  number  of  observations  enq>loyed  in  the  final  fit. 

(v)  The  best  estimate,  B,  of  attitude  at  the  reference  time  and  the 
best  estimate,  W,  of  pitch  rate. 

(vi)  All  the  attitude  measurements  not  excluded  by  the  above  2°  rule, 
with  asterisks  indicating  the  observations  used  to  derive  the  final  fit. 

(vii)  The  measurement  number  followed  by  the  observed  pitch  angle,  quoted 
relative  to  two  different  datums:  first,  relative  to  ecliptic  north  (as  in 
the  fifth  column  of  the  Pitch  Attitude  Log  - see  section  5.1);  second, 
relative  to  the  plane  defined  by  the  earth-sun  line  and  the  earth's  polar 
axis  (see  Fig  9) . 

(viii)  Miscellweous  items  for  use  if  sensor  errors  were  investigated. 

(ix)  The  assumed  height  of  the  horizon  above  sea  level. 

7.2  Gyro  Rate  of  Drift  (CROP) 

GROD  extracted  the  contents  of  the  roll  and  yaw  integrator  registers  for 
every  frame  of  recorded  data.  Using  the  best  fit  for  pitch  attitude  data,  each 
saiiq>le  was  corrected  to  take  account  of  the  earth  orbit  rate  around  the  sun. 

Time  averages  were  then  evaluated  for  all  data  obtained  in  the  pass,  and  further 


averages  for  all  the  passes  obtained  during  each  particular  period  of  constant 
pitch  rate. 


The  attitude  of  the  satellite  (as  output  by  SPAM,  ie  B and  W for  a 
specified  reference  time)  had  to  be  input  via  the  console,  together  with  the 
index  number  of  the  pass  to  be  analysed.  Such  input  was  required  for  all  the 
passes  to  be  analysed.  Lineprinter  output  consisted  of  the  mean  of  all  the 
samples  of  yaw  and  drift  rates,  and  the  number  of  samples  used. 

The  program  was  run  whenever  analysis  was  required  for  a number  of  passes 
satisfying  the  following  conditions 

(a)  the  nominal  pitch  rate  was  constant  and  did  not  exceed  30° /h; 

(b)  the  pitch  rate  had  been  at  a constant  rate  for  not  less  than  eight 

hours  (usually  data  twelve  hours  later  was  the  earliest  used) . 

8 PROGRAMS  FOR  EXPERIMENT 

8. 1 IR  Detector  Responsivities 

The  purpose  of  the  program  was  to  evaluate  the  comparative  responsivity  of 
each  of  the  four  detectors  of  the  infra-red  sensor  using  a selected  pass  of  data, 
by  analysis  of  data  samples  obtained  when  the  detectors  were  observing  space. 

For  each  detector,  when  viewing  space,  the  transmitted  signals  were  compared  with 
pre-launch  ground  calibrations  as  functions  of  sensor  in-orbit  temperature.  The 
comparisons  were  averaged  over  a large  number  of  data  samples  to  minimise  quanti- 
sation errors,  and  standard  deviations  were  provided  to  give  checks  on  the 
validity  of  data  and  sensor  performance. 

In  order  to  select  only  those  data  samples  which  were  obtained  when  each 
of  the  detectors  was  observing  space,  the  initial  and  final  frames  counts  were 
input  (via  the  console)  for  the  period  of  observation  of  each  detector,  as 
obtained  from  standard  QLK  output.  In  principle  this  task  could  have  been 
avoided  by  using  the  automatic  attitude-determination  procedures  which  were  used 
in  most  of  the  long-term  data  processing.  However,  as  these  were  still  under 
development  it  was  decided  that  the  small  amount  of  manual  effort  was  worthwhile 
in  order  to  obtain  results  rapidly.  The  program  analysed  data  for  selected 
passes  from  digital  tapes  and  the  results  were  output  to  the  lineprinter. 

8.2  Radiance  Mapping 

There  were  four  programs;  two  were  written  to  satisfy  the  initial  require- 
ments and  the  other  two  after  further  demands  were  made.  Basically,  all  four 
programs  were  constructed  and  operated  in  the  same  way.  The  programs  analysed 
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data  from  each  pass  on  a digital  tape,  scanning  each  pass  of  data  twice.  The 
first  scan  was  to  evaluate  an  attitude  model  (see  Appendix,  section  A4)  and  the 
second  to  perform  the  required  data  processing. 

The  first  three  programs  used  the  same  type  of  attitude  modelling.  Horizon 
position  fixing  data  was  available  from  the  IRl  detector,  and  the  programs  were 
used  to  analyse  data  corresponding  to  periods  when  the  satellite  was  in  Mode  3 
(inertial  sun-lock  mode)  and  had  a low  pitch  rate  - usually  ±25°/h.  The  fourth 
program  was  used  to  analyse  data  received  when  the  satellite  was  operating  in 
Mode  2 (sun  acquisition  mode)  during  the  last  month  of  its  life.  Horizon  posi- 
tion fixing  data  was  obtained  from  the  IRI  detector  and,  so  long  as  at  least  two 
fixes  were  obtained,  the  pitch-gyro  rate  outputs  could  be  integrated  and  scaled 
to  provide  an  adequate  attitude  model. 

From  a knowledge  of  the  satellite  attitude  and  orbital  position,  it  was 
determined,  for  the  IR  detector  under  consideration,  whether  or  not  the  data 
samples  were  from  observation  of  earth  or  space;  only  earth  observation  data  was 
used,  this  being  converted  into  radiance  measurements  using  the  pre-flight  cali- 
brations with  in-orbit  responsivity  evaluations  (see  section  8.1).  Using  also  a 
standard  earth-shape  the  ground  position  of  infra-red  emission  was  determined 
and  converted  into  latitude  and  longitude  (to  the  nearest  degree).  In  addition, 
for  each  sample  the  following  items  were  computed  and  tabulated:  sun-elevation 
relative  to  ground  position  (negative  if  below  horizon) ; satellite  elevation 
relative  to  ground  position;  and  the  condition  of  the  sun  with  respect  to  the 
ground  position  - continuous  dark,  continuous  light,  rising  or  setting. 

In  addition  to  the  digital  tapes,  orbital  elements  and  values  for  respon- 
sivity were  required  for  each  program,  and  the  output  was  produced  on  the 
lineprinter. 

8.2.1  Radiance  Mapping  1 

This  was  the  most  important  of  the  set  of  four  programs.  It  analysed  only 
data  from  the  IRl  detector,  which  was  the  primary  detector  of  the  infra-red 
sensor.  Full  details  of  each  radiance  san^>le  (as  described  above)  were  tabulated 
on  the  lineprinter. 

Means  and  standard  deviations  of  the  radiance  were  computed  corresponding 
to  each  of  the  latitudes  0°,  5°,  10°,  85°.  If  desired,  the  analysis 
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could  be  extended  to  a number  of  digital  tapes . At  the  end  of  processing  each 
digital  tape,  a paper  tape  of  all  carry-over  quantities  was  made,  and  checked 
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(for  punching  errors)  by  reading  it  back  in  before  program  termination.  This 
paper  tape  was  then  used  as  input  for  the  processing  of  the  next  digital  tape. 

8.2.2  Radiance  Mapping  2 

This  program  provided  radiance  mapping  information  for  all  earth-observation 
data  saiiq>les  from  detectors  IR2,  IR3  and  IR4.  There  was  no  statistical  analysis. 

8.2.3  Radiance  Mapping  3 I 

i 

This  program  was  a modification  of  Radiance  Mapping  1 . It  provided  only  j 

the  radiance  mapping  information  of  those  earth-observed  positions  where  the  | 

latitudes  were  0°,  5°,  10° 85°.  There  was  no  statistical  analysis.  j 

I 

8.2.4  Radiance  Mapping  4 

I 

This  program  was  used  when  the  satellite  was  in  Mode  2 to  give:  (i)  the  ; 

same  radiance  mapping  information  as  described  in  Radiance  Mapping  3,  and  (ii)  j 

the  same  statistical  data  as  described  in  Radiance  Mapping  1 . j 

8 . 3 IR  Horizon  Characteristics 

The  purpose  of  the  program  was  to  evaluate  the  characteristic  height  of  the 
IR  horizon,  using  data  obtained  from  the  satellite  when  operating  in  star-lock 
mode. 

I 

j 

When  the  satellite  was  in  star-lock,  two  of  the  satellite  axes  were  con-  ' 

trolled  with  reference  to  the  sun,  and  the  third  axis  with  reference  to  the 

selected  star.  Thus  potentially  the  attitude  of  the  satellite  could  be  deter-  j 

mined  very  accurately,  subject  to  good  orbital  position  determination  which  was 
itself  dependent  on  the  achievable  timing  accuracy.  The  most  suitable  detector  j 

of  the  inf ra-red  sensor  was  IRl , as  its  data-saa^ling  frequency  was  the  highest.  j 

The  direction  of  the  centre-line  of  the  IRl  field  of  view  was  almost  constant,  ; 

when  the  satellite  was  in  star-lock,  and  during  the  course  of  an  orbit  it  crossed  '< 

the  earth's  horizon  twice. 

For  each  IRl  data  sample  in  the  region  of  an  horizon  crossing,  the  Ikl  j 

centre-line  position  was  determined  accurately  from  a knowledge  of  the  star  posi-  j 

tion,  the  satellite's  orbital  position  and  the  relative  orientation  of  the  star  | 

sensor  and  the  IRl  detector  (see  Appendix) . The  data  sample  was  converted  into 
a radiance  measurement  and  the  height  of  the  centre-line  above  (or  below)  the 
earth  was  determined  using  a standard  earth-shape. 

. . 2 

The  input  to  the  program  consisted  of  a digital  tape,  RAE  orbital  elements  , 

and  right  ascension  and  declination  of  the  star.  In  addition  the  initial  and 
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final  frame  counter  values,  for  the  data  of  interest,  were  input  via  the  console; 
these  were  obtained  from  QLK  output.  The  radiance  measurements  and  horizon 
heights  were  output  to  the  lineprinter,  suitably  annotated  with  time,  etc. 

9 PROGRAMS  FOR  EXPERIMENT 

The  star  sensor,  when  actively  viewing  space,  gave  two  output  signals,  one 
giving  a measure  of  light  intensity  and  the  other  an  error  signal  which  was  a 
difference  signal  from  the  split-image  of  the  detector.  A glare  detector  was 
used  to  ensure  that  the  sensor  was  rendered  inactive  when  observing  relatively 
bright  objects  such  as  the  earth  (in  practice  for  a given  star  direction  the  star 
could  actively  be  observed  for  about  one-third  of  the  orbit).  As  a star  crossed 
the  field  of  view  of  the  detector,  the  error  signal  passed  through  a null.  The 
star-mapping  programs  could  have  used  this  principle  for  star  detection,  but 
there  were  not  many  star  crossings  and  there  were  a number  of  occasions  when  the 
background  light  intensity  was  high  - and  so  produced  an  error-signal  bias  in 
excess  of  the  error  signals  from  some  of  the  fainter  stars.  Hence  it  was 
decided  to  produce  programs  which  (for  selected  passes  of  data)  output  all  the 
active  sensor  signals. 

The  output  was  in  the  form  of  a list  on  the  lineprinter,  giving  each  pair 
of  sensor  samples  together  with  the  time  of  the  difference  sample,  and  the 
right  ascension  (a)  and  declination  (6)  of  the  centre-line  field  of  view  at 
that  time.  To  provide  a and  6,  the  attitude  of  the  satellite  had  to  be 
evaluated.  Three  methods  of  attitude  determination  were  applicable  and  covered 
mutually  exclusive  periods.  A complete  star  mapping  program  was  provided  for 
each  method  of  attitude  determination,  the  output  being  the  same. 

Each  program  used  digital  tapes  as  input  and  required  orbital  elements. 

The  calibrations  used  for  the  pitch  rates  were  those  determined  by  the  program 
SPAM  (see  section  7.1). 

9. 1 Star  Mapping  1 

This  program  scanned  the  data  from  each  selected  satellite  pass  twice,  the 
first  time  to  evaluate  an  attitude  model  and  the  second  time  to  produce  the  star 
sensor  data.  The  attitude  model  used  horizon  position  fixing  data  from  the 
100-element  albedo  sensor,  obtained  when  the  satellite  was  rotating  about  the 
pitch  axis  at  approximately  orbit  rate. 

9.2  Star  Mapping  2 

This  program  scanned  the  data  from  each  selected  satellite  pass  just  once, 
to  produce  the  star  sensor  data.  The  attitude  information  was  input  in  the  form 
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of  two  attitude-time  points  and  an  approximate  pitch-rate,  via  the  console.  The 
program  was  used  on  data  recorded  when  the  satellite  was  rotating  at  orbit  rate 
with  the  100-element  albedo  sensor  set  to  its  lowest  sensitivity,  as  in  this 
configuration  there  was  no  horizon  position  fixing  data  available  for  attitude 
modelling. 

9.3  Star  Mapping  3 

This  program  scanned  the  data  from  each  selected  satellite  pass  twice,  the 
first  time  to  evaluate  an  attitude  model  and  the  second  time  to  produce  the  star 
sensor  data.  The  attitude  model  used  horizon  position  fixing  data  from  the  infra- 
red sensor,  obtained  when  the  satellite  was  rotating  about  the  pitch  axis  at  a 
rate  less  than  25°/h  in  magnitude. 

10  PROGRAMS  FOR  EXPERIMENT 

Three  programs  were  used  in  the  analysis  of  the  distribution  of  albedo 
intensity  near  the  t^erminator,  known  as  DIHTl , DINT2  and  DINT3.  The  first  two 
programs  were  used  when  the  satellite  was  in  the  special  earth-pointing  mode, 
while  the  third  covered  periods  when  the  pitch  rate  was  held  constant,  in  the 
numerical  range  8°/h  to  25°/h,  for  periods  of  two  or  three  days.  The  albedo 
sensor  had  three  integration  times  (known  as  sensitivity  settings),  viz  16  ms, 

4 ms  and  1 ms.  With  an  integration  time  of  either  16  ms  or  4 ms,  attitude  could 
be  determined  from  data  collected  by  the  100-element  array,  but  for  1 ms  ii  e- 
gration  time  this  was  not  possible  and  a pair  of  independent  attitude-time 
points  had  to  be  provided  via  the  console. 

The  objective  of  the  DINT  programs  was  to  analyse  the  response  of  the 
elements  of  the  albedo  sensor  in  relation  to  the  variable  intensity  of  illumina- 
tion near  the  terminator,  the  results  being  expressed  in  terms  of  'probability 
of  albedo  trigger'.  For  DINTl  and  DINT2  this  probability  was  tabulated,  for  each 
sensitivity,  against  a 'latitude  angle',  6,  relative  to  the  nominal  terminator. 
(The  nominal  terminator  was  defined  by  the  geocentric  plane  perpendicular  to  the 
sun-line,  6 being  taken  as  positive  for  points  on  the  sunlit  side.)  For  DINT3 
the  tabulation  was  against  local  elevation  angle,  a,  as  well  as  6. 

A DINT  survey  consisted  of  the  analysis  of  a number  of  passes,  from  one  or 
more  digital  tapes.  The  programs  asked,  for  each  pass,  whether  or  not  the  pass 
was  required  for  the  survey,  so  a list  of  the  required  passes  had  to  be  prepared 
in  advance.  If  a survey  could  not  be  completed  in  a single  session  with  the 
computer,  a continuity  facility  was  employed,  involving  a carry-over  paper  tape 
as  with  Radiance  Mapping  1 (see  section  8.2.1). 
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10. 1 IlluminaCion  distribution  (DIMTl) 

DlMTl  was  used  only  for  sensitivities  of  4 ms  and  16  ms,  when  the  program 

could  determine  its  own  attitude  model  for  each  pass.  If,  through  lack  of 

horizon  crossings,  this  determination  was  not  possible,  the  pass  in  question  was 
rejected.  The  program  scanned  the  data  (for  each  pass)  twice,  the  first  scan  to 
evaluate  the  attitude  model  and  the  second  to  analyse  the  sensor  data  in  detail . 
From  a knowledge  of  attitude  and  array  orientation,  the  array  elements  pointing 
to  earth  and  space  were  determined.  For  each  element  pointing  towards  the  earth, 
the  latitude  angle  6 of  the  ground  position  observed  relative  to  the  terminator 
w«8  determined,  the  region  of  interest  being  from  6 « -5.5°  to  6 > 20.5° 

divided  into  26  l°-bands.  The  program  reserved  a pair  of  storage  locations  for 

each  of  the  26  bands,  effectively  an  ON  box  and  an  OFF  box,  and  for  each  element 
observing  the  earth,  corresponding  to  one  of  the  bands,  the  appropriate  box  was 
incremented. 

The  contents  of  the  ON  and  OFF  boxes  for  each  of  the  1°  bands  were  listed 

on  the  lineprinter  at  the  end  of  each  pass,  results  from  preceding  passes  of  the 

survey  being  included.  At  the  end  of  the  survey  the  trigger  probability  table 
was  output. 

10.2  Illumination  distribution  (OINT2) 

DINT2  differed  from  DINTl  in  that  it  was  used  for  the  1 ms  sensitivity 
setting,  when  the  attitude  model  had  to  be  provided  via  the  console.  For  the 
pair  of  attitude-time  points  required,  one  time  had  to  be  prior  to  the  commence- 
ment of  the  first  pass  of  the  survey  and  the  other  subsequent  to  the  termination 

of  the  last  pass.  It  was  essential  that  the  pitch  rate  was  not  changed  between 

these  times. 

10.3  Illumination  distribution  (DINT3) 

DINT3  based  its  attitude  model  on  horizon  fixing  from  IR-sensor  data, 
instead  of  from  the  albedo  sensor.  Analysis  was  similar  to  that  for  DINTl,  but 
a second  angle  was  required  for  the  ground  position  observed  by  each  array  ele- 
ment, viz  the  elevation  angle  a of  the  satellite  from  that  ground  position. 

Thus  the  data  in  the  ON  and  OFF  boxes  was  accumulated  for  a range  of  a values 
as  well  as  a set  of  6 bands.  (However,  only  one  sensitivity  was  covered,  since 
data  was  only  available  for  16  ms  sensitivity.)  There  were  only  12  l°-bands  for 
6 this  time,  covering  the  range  -5.5°  to  6.5°.  The  a subdivision  was  based 
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on  rounding  at  to  the  nearest  5°  and  accumulation  for  17  values,  viz  10°,  15°, 

20° 90°.  The  line  printer  table  at  the  end  of  a survey  was  of  trigger 

probabilities  for  the  204  (12  x 17)  pairs  of  6,  a values. 

11  OTHER  EXPERIMENTS 

For  Experiment  E no  long-term  data  processing  was  required  as  all  its  data 
processing  was  incorporated  in  QLK. 

There  was,  however,  one  unplanned  experiment.  After  launch,  when  it  was 
found  that  automatic  processing  of  attitude  data  could  be  achieved,  it  was 
realised  that  Miranda  offered  a unique  in-orbit  test-platform  for  aerial  polar 
diagram  measurements. 

11.1  Aerial 

This  was  the  program  which  evaluated  the  aerial  polar-diagram  angles,  6 
and  1^.  The  program  used  the  attitude  model  based  on  the  IRl  detector.  With  a 
knowledge  of  the  ground  position  and  the  satellite  attitude,  the  orientation  of 
the  satellite  relative  to  the  ground-station  antenna  was  evaluated  in  terms  of 
6 and  ((i . 

The  program  used  digital  tapes  and  orbital  elements  as  input  data,  and 
produced  lineprinter  listings  of  6 and  0 (as  functions  of  time)  to  be  used 
in  conjunction  with  the  AGC  ground  recordings  made  at  Lasham,  the  ground  station. 

12  CONCLUDING  REMARKS 

The  success  of  the  Miranda  data  processing  can  be  measured  by  the  fact 
that  all  planned  objectives,  and  indeed  a number  more,  were  met  within  a year 
of  launch.  This  was  largely  a consequence  of  having  structured  the  software  in 
such  a way  as  to  allow  easy  modification  of  existing  requirements  and  inclusion 
of  further  requirements.  The  structuring  took  full  advantage  of  the  fact  that 
all  the  data  for  one  day  was  on  one  magnetic  tape,  thus  simplifying  the  operator 
interaction  and  increasing  the  reliability. 

For  data  processing  on  similar  satellites  it  is  recommended  that  the  same 
philosophy  be  used  with  small  changes  in  detail,  in  particular :- 

(i)  ensure  that  the  Quick  Look  and  Routine  Look  programs  cover  all  sub- 
systems thoroughly  but  concisely; 

(ii)  provide  an  abbreviated  version  of  the  pitch  attitude  log  containing 

only  the  major  operational  and  attitude  events; 

(iii)  make  the  Emergency  Look  program  more  flexible,  by  allowing  data  to  be 

requested  in  engineering  units,  as  an  alternative  to  decimal  and  octal. 
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I Appendix 

I SOFTWARE  STRUCTURE 

A.  1 Philosophy 

When  work  started  on  the  design  and  implementation  of  the  software  system 
[ for  support  of  Miranda  non-real-time  operations  and  data  processing,  only  broad-  i 

line  requirements  were  defined;  certain  requirements  were  not  even  definable 
before  launch.  The  software  system  had  to  be  sufficiently  flexible  to  allow  for 
this  situation. 

The  format  of  data  storage  was,  however,  decided  at  an  early  stage, 
viz:  one  digital  tape  per  day  of  data  (with  magnetic  tape  formats  also  specified 
''  at  this  stage,  as  given  in  Ref  2).  It  naturally  followed  that  the  data  control 

I routines  should  be  made  into  one  or  more  software  packages.  Furthermore,  orbital-  1 

position  and  sun-direction  software  was  available,  and  since  not  all  users 
required  orbital  or  sun  data,  these  would  naturally  form  independent  packages. 

The  attitude  reconstruction  required  independent  packages  which  could  only  be 
completed  after  in-orbit  assessment  of  the  pitch-rate  monitors.  Finally,  the  | 

user  requirements  were  built  into  independent  packages,  many  of  which  were  | 

available  before  launch,  while  others  were  defined  as  a result  of  in-orbit  j 

experience.  i 

A. 2 Data  control  I 

1 i 

The  data-control  software  interfaced  between  the  operator  and  computer,  ^ 

and  controlled  the  flow  of  data  from  selected  digital  magnetic  tapes.  Data  was  i 

processed  serially  from  a pass  or  group  of  passes,  and  presented  to  the  user 

i 

routines  frame-by-frame,  suitably  formatted,  together  with  control  flags  and  j 

corrected  times,  appropriate  to  direct  or  recorded  data.  This  software  was  | 

integrated  into  six  packages,  two  without  attitude  reconstruction  and  four  with  1 

(see  section  A. 4).  | 

A. 3 Satellite  position  and  sun  direction  j 

Two  sets  of  routines  for  determination  of  satellite  position  were  in 
existence  (as  described  in  Ref  2),  with  corresponding  routines  for  sun  position.  ' 

These  sets  of  routines  needed  only  minor  modification  to  make  them  into  modular- 
ised packages.  The  two  packages  were  made  to  appear  identical  to  the  user  and 
so  were  directly  interchangeable.  One  package  omitted  some  of  the  smaller  orbit 
I perturbations  but  was  adequate  for  many  requirements.  However,  it  was  necessary  i 

to  use  the  more  accurate  package  when,  for  example,  the  satellite  was  in  star-lock.  I 
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A. 4 Attitude  reconstruction 

Many  of  the  data  processing  requirements  for  experiments  B,  C and  D needed 
accurate  attitude  information.  The  attitude  reconstruction  was  performed  only 
during  periods  of  constant  pitch  rate  and  was  made  available  to  the  user  via  the 
controlling  routines.  Four  versions  were  available  - in  three  of  these  the  data 
from  a pass  was  scanned  twice,  the  first  scan  to  create  an  attitude  model  and  the 
second  to  offer  the  data  to  the  user.  Since  the  pitch  axis  was  kept  in  the  sun- 
pointing direction  the  attitude  of  the  satellite  was  fully  defined  by  the  pitch 
angle.  The  four  versions  of  attitude  model 

(i)  Attitude-time  points  were  obtained  from  horizon  crossings  of  infra- 
red detector  IRI . The  pitch  rates  were  evaluated  from  the  telemetry  data 
and  modified  according  to  in-orbit  calibrations.  A best  fit  through  the 
attitude-time  points  was  taken  at  the  evaluated  pitch  rate. 

(ii)  Attitude-time  points  were  obtained  from  horizon  indications  of  the 

1 00-element  array  albedo  sensor.  Otherwise  the  attitude  was  reconstructed 
as  in  (i). 

(iii)  Two  selected  attitude-time  points,  plus  an  approximate  inclusive 
pitch  rate,  were  input  via  the  console.  The  software  evaluated  the  pitch 
rata  to  satisfy  the  given  attitude-time  points. 

(iv)  Attitude-time  points  were  obtained  from  horizon  crossings  of  the 
infra-red  detector  IRl . The  pitch-gyro  rate  outputs  were  integrated  and 
suitably  scaled  to  fit  these  points. 

Versions  (i)  to  (iii)  could  be  used  to  give  extremely  good  attitude  data 
when  the  satellite  was  in  Mode  3 (inertial  sun-lock  with  fine  sun-sensing)  but 
could  also  be  used  to  give  reasonable  attitude  data  when  the  satellite  was  in 
Mode  3A  (inertial  sun-lock  back-up  using  only  the  prime  sun  sensor  - with 
resulting  errors  in  sun-pointing  caused  by  albedo  contamination) . Version  (iv) 
could  be  used  to  give  reasonable  attitude  data  when  the  satellite  was  in  Mode  2 
(sun-acquisition  mode  - used  when  part  of  the  satellite's  orbit  was  eclipsed). 

An  independent  attitude  reconstruction  was  necessary  for  Experiment  A 
because  of  these  varying  requirements: 

(i)  Experiment  A required  almost  immediate  data  processing,  while  long- 
term processing  was  adequate  for  the  other  experiments. 
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(it)  Experiments  B,  C,  0 ideally  required  coiiq>leCe  automatic  processing 
of  attitude  data,  while  for  Experiment  A interactive  processing  was  not 
only  acceptable  but  desirable. 

(iii)  Experiment  A used  a different  set  of  attitude  reference  axes  from 
the  other  experiments. 

Fig  9 shows  the  axis  systems.  For  Experiment  A the  important  feature  was 
that  the  gyros  gave  a reference  relative  to  inertial  space.  The  axis  system 
chosen  incorporated  the  sun-line  (s)  and  the  ecliptic  north  (e) . The  satellite 
attitude  was  defined  as  the  angle  between  the  yaw  axis  and  the  ecliptic  north 
(assuming  the  pitch  axis  to  be  sun-pointing) . 

For  the  other  experiments,  all  observations  were  of  items  whose  position 
was  referenced  in  terms  of  earth  axes.  A vector  p (pseudo-north)  was  defined 
such  that  p was  in  the  plane  containing  the  north  polar  direction  (n)  and  sun- 
line (s),  and  perpendicular  to  the  sun-line.  The  satellite  attitude  was  defined 
as  the  angle  between  the  yaw  axis  and  the  pseudo-north  direction  (assuming  the 
pitch  axis  to  be  sun-pointing). 

As  can  be  seen  from  Fig  10,  if  the  satellite  position  and  the  sun  direc- 
tion were  known  at  the  time  of  an  horiaon  fix  from  one  of  the  detectors,  the 
satellite  attitude  could  be  obtained  in  either  axis  system. 

The  attitude  reconstruction  for  experiment  A was  incorporated  in  the  user 
routines  for  that  experiment. 

A. 5 User  software 

Fig  11  shows  how  user  routines  dealt  with  the  data.  The  controlling  rou- 
tines offered  the  data  plus  appropriate  flags  to  the  user  routines  (by  way  of 
common  storage)  after  each  data  block  had  been  read  from  the  digital  magnetic 
tape.  The  entry  point,  as  shown  in  Fig  11,  could  be  replaced  in  practice  by  a 
sequence  of  entry  points  to  individual  user  routines.  This  allowed  processing 
of  several  requirements  to  be  performed  in  parallel  on  a serial  data  stream, 
while  remaining  mutually  exclusive. 

A. 6 Program  construction  and  use 

Satellite-data-processing  programs  and  operations-support  programs  con- 
sisted of  one  or  more  user  routines  and  a controlling  package,  together  with 
orbit  and  attitude  packages  as  necessary. 
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Appendix 

All  prograaw  ware  stored  in  binary  on  disc  or  magnetic  tape,  with  operating 
instructions  available  in  a supplement  to  the  Operations  Manual.  Each  program 
was  loaded  into  the  computer  by  the  operator  according  to  the  scheduled 
requirements. 
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